Increasingly, commerce and other exchanges that involve payment transactions such as those occurring in conjunction with commerce or charity or nonprofit organizations have moved into the online world. For example, online fundraising is now a significant portion of the fundraising and capital campaigns of many nonprofit organizations. The implementation of these payment transactions in the online world has given rise to specific problems that occur as a consequence of the fact that such payment transactions now take place in the context of, and utilizing communication that travel over, these highly distributed computer networks.
Typically, a distributed computer environment in which monetary transfers is made include computers belonging to an organization, such as a for-profit or not-for-profit business or association (collectively referred to herein as a merchant) coupled to one or more separate payment gateway computers over a network, most often the Internet. These payment gateways are entities that are application service providers that authorize credit card transactions and conduct or facilitate settlement between participating institutions (e.g., banks, credit unions, etc.). User computing devices such as a personal computer, laptop computer, mobile phone or other computing device, are also coupled to the network.
In many cases, the merchant computers may provide a site comprised of various web pages or other content (collectively, “web page”) which the user can access over the network utilizing a browser or application (e.g., “app”) executing on his device. At least one of those web pages includes a portion of a page (which may be an entire page, pop-up, frame, div, iframe, etc.) through which the user may initiate a payment transaction when the page is rendered at the user's device by the browser. These payments can be made in exchange for goods or services, can simply be donations, or can be made for other reasons.
A payment gateway or separate payment system may host a secure payment interface (e.g., web page, application programming interface (API), etc.) through which the initiated payment may actually be completed. Thus, when the user accesses the web page from the merchant utilizing his browser, the user interacts with the payment portion of the page for example, by activating a payment control (e.g., a payment button). The user may also optionally enter personal or payment-related information within this portion of the page. When all required personal and/or payment-related information is entered, the user may provide a further input, such as selection of a “submit” button, to signify readiness to actually complete the payment transaction.
In response to receipt of the input signifying user readiness to complete the payment the browser can then be redirected to a secure payment web page hosted on the payment gateway server. In performing the redirection, the user-entered personal or payment-related information may also be transmitted to the payment web page hosted by the payment gateway.
In many cases, following the redirection, the user completes the payment by interacting with the payment gateway's web page. For example, the user may enter credit card information or bank account and routing information through the payment interface in order to complete the payment. The payment gateway server typically confirms completion of the financial payment by the user by serving to the user's browser a confirmation page.
When making an online payment such as that described above, users have two primary concerns, namely, security and authenticity. Security is a concern because users do not want their private personal or financial information intercepted and misused. Authenticity is also a concern because users want payments to be received by the intended merchant rather than an unknown third party. The conventional payment infrastructure described above attempts to address these concerns through authentication with a “trusted” third party that is presumed to be viewed as reliable by users. In many cases, the “trusted” third party provides a badge or seal. Users can allay concerns regarding the authenticity of the party hosting sub-window by clicking on the badge or seal to establish communication with the “trusted” third party over network to enable confirmation of the authenticity of the party.